Brought to you by EarthWeb
IT Library Logo

Click Here!
Click Here!


Search the site:
 
EXPERT SEARCH -----
Programming Languages
Databases
Security
Web Services
Network Services
Middleware
Components
Operating Systems
User Interfaces
Groupware & Collaboration
Content Management
Productivity Applications
Hardware
Fun & Games

EarthWeb Direct EarthWeb Direct Fatbrain Auctions Support Source Answers

EarthWeb sites
Crossnodes
Datamation
Developer.com
DICE
EarthWeb.com
EarthWeb Direct
ERP Hub
Gamelan
GoCertify.com
HTMLGoodies
Intranet Journal
IT Knowledge
IT Library
JavaGoodies
JARS
JavaScripts.com
open source IT
RoadCoders
Y2K Info

Previous Table of Contents Next


Online Transaction Process (OLTP) Systems

OLTP systems include retail store systems, order entry for inside sales departments, automated banking systems, and other systems where customers (i.e., clients) wait while system users process their transaction in real time.

Real-Time Decision Support Systems

Examples of real-time decision support systems include any financial trading desk where buy/sell decisions must be made in an environment where prices change minute by minute. Not making a decision or making an uninformed decision can be extremely costly. In some complex manufacturing environments, a continuous monitoring system is in operation that provides real-time information which, if unavailable, could result in costly scrapping of material in process. In an operating room or intensive-care unit, patient monitoring systems provide real-time information that could cost a patient’s life if it were unavailable to the attending physician.

In each of these critical path examples, the function of the network or network segment is of far greater value than the payroll cost of those directly using the system. The output valuation method only considers the value of the output of the user or work group versus the payroll cost of the user or work group. In the critical path example shown in Exhibit 1-6-2, a systems development team is working on a branch office automation system that is expected to save $3.5 million in annual operating expenses for the company. Delays in system development will delay the realization of these anticipated cost savings, thus adding significantly to the direct cost of systems downtime.


Exhibit 1-6-2.  Network System Valuation Calculation

Indirect Costs of Downtime

Quantification of indirect costs is difficult if not impossible. Even so, lost future business and costs of work flow interruption need to be considered.

Image Loss Results in Lost Business. Customer frustration can be triggered by something as minor as waiting a little too long for processing of an order or something as significant as a supplier’s losing track of a time-sensitive shipment. One business model assumes that 0.1% of customers affected by a system failure will switch their business to a competitor. If those customers who switch to a competitor represent average customers, the image loss would be 0.1% of annual sales volume. If the frustrated customer is a large account, or if the company’s business is in a highly competitive industry, lost future business could be much larger than 0.1% of sales.

Creative Productivity Loss from the Interruption of Workflow. The least likely scenario is the infinite value of the idea that got away. More likely is the amplification of interruption time that occurs among creative workers who break concentration and lose work flow momentum due to systems faults that interrupt the creative process. For these workers, “re-contexting” time can extend the actual time cost of the system fault.

Determining Repair Costs in Time and Money

The direct cost of system downtime is the time value of the system multiplied by the time it takes to repair the system and recover from the fault (mean time to repair [MTTR]). The actual costs to repair or recover from the fault must be added to this.

Mean Time to Repair (MTTR)

Mean time to repair is dependent on fault detection, service response time, and systems recovery time.

Detection time can differ according to the user. A direct user may know immediately when the system is down. However, the person with the responsibility for systems uptime and the authority to initiate any necessary recovery or repair procedures may not be aware of the fault until users report it.

Sophisticated network management systems can predict faults, making possible proactive responsive and preventing downtime. Some network management platforms have device-specific management applications for remote monitoring and diagnosis of network devices. This facilitates rerouting around the fault or prediagnosing the fault to better prepare the field technician for a quick hardware repair.

Service response time is typically controlled by an agreement with a service provider. The agreement guarantees some response time (ranging from a few hours to days), and covers all parts and labor under a fixed pricing schedule. Some agreements include options for hot spares, which guarantee immediate availability of any needed replacement parts.

System recovery and data restoration time can be a brief as the time it takes to replace a failed hard drive and restore from backup take or from a mirrored drive. Costs can include the labor costs and elapsed time costs of reentering the data from hard copy archives. The worst case is if the data is unrecoverable because no backup or other data security procedures were followed.

Risk Analysis

There are two elements of a system fault risk analysis. The first has to do with the failure rates of network hardware. The second has to do with the site-dependent risk.

System Mean Time Between Failures (MTBF)

The probable failure rate of the system is a function of the combined failure probabilities of the components of the network—the file servers, disk systems, adapter cards, hubs, cable segments, workstations, and software. Each has its own probability of failure, usually represented by the MTBF statistic.

MTBF is a very difficult number to calculate. There is a military specification for calculating a device’s MTBF by combining the failure probabilities of discrete components. Most manufacturers ignore this procedure because it is time-consuming and inaccurate. Other methods include laboratory stress tests and field observation.


Previous Table of Contents Next

footer nav
Use of this site is subject certain Terms & Conditions.
Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details.